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INTEGRATING LIVE CHAT INTO AN ONLINE CREDIT CARD 



APPLICATION 

CROSS REFERENCE TO RELATED APPLICATIONS 

This application claims priority to U.S. Patent Application No. 09/185,201 
entitled: "Method And Apparatus For Real Time On Line Credit Approval", filed 
November 3, 1998, which is herein incorporated by reference; and United States Patent 
Application No. 09/185,878 entitled: "Method And Apparatus For A Verifiable On Line 
Rejection Of An Applicant For Credit", filed November 3, 1998, which is herein 
incorporated by reference; and United States Patent Application No. 09/185,000 entitled: 
"Method And Apparatus For An Account Level Offer Of Credit And Real Time Balance 
Transfer", filed November 3, 1998 which is herein incorporated by reference. This 
application is related to Attorney Docket No. NEXTP006 filed concurrently herewith 
entitled: "Implementing A Counter Offer For An On Line Credit Card Application" 
which is herein incorporated by reference. 



FIELD OF THE INVENTION 

The present invention relates generally to online transactions. More specifically, 
integrating live chat into an online credit card application is disclosed. 
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BACKGROUND OF THE INVENTION 

Considerable marketing effort is involved in getting an applicant to log on to a 
credit card website and apply for a credit card. In addition to advertising, credit cards 
that allow a user to apply for a card over the Internet in some cases pay significant 
referral fees to a party that refers an applicant to the site. Given the effort and cost 
required to attract an applicant to begin an on-line credit card application, it is very 
important that, if at all possible, the applicant be encouraged to complete the process. 

Various reasons exist why an applicant might cancel out of a credit card 
application that has already been started. The applicant may become confused during the 
process and may cancel when the applicant is unable to discern how to follow certain 
instructions. Also, an applicant may reject an offer for credit because of some attribute of 
the credit offer that the applicant finds unacceptable. Whatever the reason that the 
applicant does not complete the process and receive the credit card, the loss to the 
marketer of the credit card is significant. It would be very helpful if an on line credit card 
application system could be improved to reduce the number of applicants that stop the 
process short of obtaining a credit card. 
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SUMMARY OF THE INVENTION 



An on line credit card application system that provides an integrated live chat to 
help the applicant during an application process is disclosed. In one embodiment, an 
application that initiates a chat session with a chat server is provided to the applicant's 
browser. When an event that occurs that indicates that the applicant may be helped by 
chatting with a customer service agent on line, a chat application contacts the chat server 
and places the applicant in a queue to chat with the next available customer service agent. 
In one embodiment, the chat application on the applicant's browser does not send 
detailed information about the application to the chat server. Instead, the chat application 
sends an applicant identifier to the chat server. The chat server then accesses the 
application server that has been handling the application session with the applicant and 
uses the applicant identifier to access information about the application. 

It should be appreciated that the present invention can be implemented in 
numerous ways, including as a process, an apparatus, a system, a device, a method, or a 
computer readable medium such as a computer readable storage medium or a computer 
network wherein program instructions are sent over optical or electronic communication 
links. Several inventive embodiments of the present invention are described below. 

In one embodiment, a method of providing on line chat help to an applicant 
includes inserting an application identifier and a chat applet into a web page. The web 
page is sent to the applicant. The chat applet is configured to determine upon the 
occurance of an event that the applicant could benefit from online chat and, upon such 
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determination, to send a request to a chat server for a connection and to include the 
application identifier with the request. 

In one embodiment, a method of providing on line chat help to an applicant 
includes receiving a request for a chat connection and a corresponding application 
identifier. A chat connection is established with the client. The applicant identifier is 
used to obtain information from a remote server about an application that the applicant is 
in the process of completing. 

In one embodiment, a method of providing on line chat help to an applicant 
includes receiving a web page including an applicant identifier. It is determined that the 
applicant could benefit from online chat and a request is sent to a chat server for a 
connection wherein the request includes the application identifier. 

In one embodiment, an application server for providing on line chat help to an 
applicant includes a processor configured to insert an application identifier and a chat 
applet into a web page and an applicant interface configured to send the web page to the 
applicant. The chat applet is configured to determine based on an event that the applicant 
could benefit from online chat and, upon such determination, to send a request to a chat 
server for a connection and to include the application identifier with the request. 

In one embodiment, a chat server for providing on line chat help to an applicant 
includes an applicant interface configured to receive a request for a chat connection and a 
corresponding application identifier and to establish a chat connection with the client. A 
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server interface is configured to use the applicant identifier to obtain information from a 
remote server about an application that the applicant is in the process of completing. 

In one embodiment, an applicant client for obtaining on line chat help includes an 
application server interface configured to receive a web page including an applicant 
identifier. A processor is configured to determine that the applicant could benefit from 
online chat. A chat interface is configured to send a request to a chat server for a 
connection wherein the request includes the application identifier. 

These and other features and advantages of the present invention will be presented 
in more detail in the following detailed description and the accompanying figures which 
illustrate by way of example the principles of the invention. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



The present invention will be readily understood by the following detailed 
description in conjunction with the accompanying drawings, wherein like reference 
numerals designate like structural elements, and in which: 

Figure 1 is a block diagram illustrating a system for providing real time chat help 
to an applicant and generating a counter offer when appropriate. 

Figure 2 is a flowchart illustrating a general process implemented on the chat 

server. 

Figure 3 is a flow chart illustrating a general process implemented on the web 
server for sending dynamic web pages to the applicant. 

Figure 4 is a flow chart illustrating a process implemented on a browser for 
establishing a connection to a chat server. 

Figure 5 is a flowchart illustrating a typical process implemented on the browser 
for the purpose of initializing chat when the user does not respond to a downloaded web 
page in a certain period of time. 

Figure 6 is a flow chart illustrating a process implemented on a chat server when a 
chat session is requested by a browser as described above. 

Figure 7 A is a flow chart illustrating a process implemented at a customer service 
agent for the purpose of supporting the chat session. 
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Figure 7B is a screen shot illustrating a display of offer terms used in one 
embodiment for determining which terms are unacceptable. 

Figure 8 is a flow chart illustrating in detail a process implemented in step 712 for 
obtaining the unacceptable terms of an offer from an applicant. 

Figure 9 is a flow chart illustrating the process implemented on the counter offer 
server when more than one term is selected as being unacceptable to the applicant. 

Figure 10 is a flow chart illustrating an example process for generating a counter 

offer. 

Figure 1 1 is a flowchart illustrating a process implemented on a counter offer 
server to generate and confirm a new offer for display to the applicant. 

Figure 12 is a flowchart illustrating a process implemented on the web server 
portion of the application server for the purpose of displaying a new counter offer to the 
applicant. 

Figure 13 is a flow chart illustrating a process used in one embodiment to 
automatically generate a refresh on the applicant's browser. 
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DETAILED DESCRIPTION 

A detailed description of a preferred embodiment of the invention is provided 
below. While the invention is described in conjunction with that preferred embodiment, 
it should be understood that the invention is not limited to any one embodiment. On the 
contrary, the scope of the invention is limited only by the appended claims and the 
invention encompasses numerous alternatives, modifications and equivalents. For the 
purpose of example, numerous specific details are set forth in the following description in 
order to provide a thorough understanding of the present invention. The present 
invention may be practiced according to the claims without some or all of these specific 
details. For the purpose of clarity, technical material that is known in the technical fields 
related to the invention has not been described in detail so that the present invention is 
not unnecessarily obscured. 

In one embodiment, an applicant interacts with a web server and receives a web 
page containing offers of credit that may be accepted by the applicant. At any point 
during the interaction with the web server, an online chat button or process may be 
activated that sends an applicant ID to a chat server and opens a chat window so that the 
applicant can receive help. In one embodiment, the help takes the form of the applicant 
describing why a displayed offer is unacceptable and a counter offer being generated for 
the applicant. 

Figure 1 is a block diagram illustrating a system for providing real time chat help 
to an applicant and generating a counter offer when appropriate. A web server 102 is in 



Attorney Docket No. NEXTP005C1 



8 



PATENT 



communication with an application database 103. Application database 103 is used to 
store information about the applicant and the application. The information stored 
includes information provided by the applicant as well as information derived from 
various credit bureaus (not shown) that are accessed by the web server either directly or 
indirectly. Each application included in the application database is referenced by an 
applicant identifier that can be used to identify the application. 

Web server 102 provides a web page 104 to a browser 106. Typically, the web 
server and browser communicate over the Internet using HTTP. Web page 104 is shown 
for the purpose of illustration as an offer web page that includes three offers made to the 
applicant for a credit card as well as an on-line chat button that may be activated by the 
applicant to obtain help or to discuss the offers. Other web pages provided by the web 
server include forms that the applicant fills out to provide information so that a credit 
report may be obtained and an offer of credit generated based on the applicant's personal 
information. 

An online application process for a credit card is described in detail in United 
States Patent Application No. 09/185,201, Attorney Docket No. NEXTP001, entitled: 
"Method And Apparatus For Real Time Online Credit Approval", filed November 3, 
1998, which was previously incorporated by reference; and United States Patent 
Application No. 09/185,878, Attorney Docket No. NEXTP002, entitled: "Method And 
Apparatus For A Verifiable Online Rejection Of An Applicant For Credit", filed 
November 3, 1998, which was previously incorporated by reference; and United States 
Patent Application No. 09/185,000, Attorney Docket No. NEXTP003, entitled: "Method 
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And Apparatus For An Account Level Offer Of Credit And Real Time Balance 
Transfer", filed November 3, 1998 which was previously incorporated by reference. 

It should be noted that the process described herein will refer to the online credit 
application as being an application for a credit card. The process can also be applied to 
other offers of credit including an offer of instant credit for the purpose of consummating 
a single pending online transaction. In addition, the system and processes disclosed 
herein may be applied to other types of business transactions over the Internet. However, 
the particular architecture and processes described are especially useful for processing 
online credit card applications and the benefit of their application to online credit card 
applications is particularly strong. 

Web server 102 and browser 106 continue to interact in a standard fashion with 
web pages being provided by web server 102 and the applicant filling out information as 
needed. At some point, an applicant may activate the online chat button included on the 
web page and a chat window 104a opens up for the chat application and a connection is 
established with a chat server 108. As is described further below, the chat window is 
opened and the connection with chat server 108 may be initiated by events other than just 
the activation of the online chat button. Chat server 108 implements a standard chat 
environment such as the chat environment available from e-share. Other chat 
environments may be used that include the ability to pass a variable to the chat server 
from the browser. 
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The various servers shown in Figure 1 may be implemented on any typical 
platform such as a Windows NT platform, a Linux platform, or other UNIX platform or 
other commercially available web server platform. The browser may be implemented on 
any system such as a Macintosh or a PC which are readily available. 

In some embodiments, the chat process is initiated when the applicant cancels out 
of the application. In other embodiments, the chat process is initiated when the applicant 
lingers on a page for an amount of time that exceeds a threshold. In other embodiments, 
the chat process is initiated when the applicant's response to a request for information is 
somehow inadequate. For example, it may be detected that the answers provided by the 
applicant are incomplete or in the wrong form. The chat process may be initiated for the 
purpose of providing the applicant more detailed instructions or pointing out to the 
applicant the information that is required to complete the application. 

In addition to opening the chat connection to chat server 108, browser 104 also 
sends the applicant identifier to the chat server. The chat server then uses the applicant 
identifier to access information about the application in the application database. It 
should be noted that the applicant identifier may be used as an application identifier in 
circumstances such as would be expected for an online credit card application where 
there is one and only one application per applicant. In other embodiments, an application 
identifier that is unique for each application is assigned and used. In this description, 
wherever an applicant identifier is mentioned, an application identifier could also be 
used. 
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Sending the applicant identifier to the chat server instead of sending the current 
web page or other information to the chat server is preferable from a security standpoint 
because the applicant identifier can only be used to obtain information about the 
application by accessing application database 103. In addition, preferably, the applicant 
identifier is encrypted, adding a further level of security. 

In the embodiment shown, chat server 108 does not have a direct link to the 
application database 103. Chat server 108 is connected to a customer service agent 110. 
Customer service agent 110 handles the chat session, responding to requests made by the 
applicant. Other customer service agents 112 and 1 14 are also standing by to handle 
other chat sessions generated by chat server 108. In one embodiment, requests made to 
the chat server are queued and the next available customer service agent is assigned to the 
first chat session request found in the queue. 

Customer service agent 1 10 is connected to a counter offer server that is 
connected to application database 103. By passing the applicant identifier from the chat 
server to the customer service agent to the application database through the counter offer 
server, information about the applicant can be obtained from the application database. 
Connections from the customer service agent to the counter offer server and from the 
counter offer server to the application database may be made over the Internet or may be 
a dedicated secure connection. 

In the embodiment shown, which is adapted specifically for implementing a 
counter offer strategy as is described below, a separate web server 102 and counter offer 
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server 120 are shown. This divides the processing demand generated by normal 
communication with a browser from the processing demand generated by interaction 
initiated by chat with a customer service agent. This architecture is particularly useful 
since the two types of traffic are isolated. In other embodiments, the functions of the web 
server and the counter offer server are performed by a single application server. Dashed 
box 122 represents a single application server that may include both the web server and 
the counter offer server. In general, the term application server is used to describe either 
the web server and counter offer server operating collectively or to describe a single 
server performing both the function of the web server and the counter offer server. 

Additionally, in a system where a counter offer is not generated, counter offer 
server 120 may be referred to as a customer service agent server or some other term 
describing its primary function. The important point is that both the web server and the 
counter offer server both access the application database to obtain information about the 
status of the application. In addition, both the web server and the counter offer server 
may write data to the application database in some embodiments. The common access to 
the application database enables the customer service agent to obtain information about 
the status of the application using the applicant identifier received through the chat server 
and also allows the customer service agent to alter the status of the application based on 
information received from the applicant through the chat server by sending that 
information to the counter offer server for posting to the application database. 

Thus, an applicant provides information to database 103 via the Internet using 
web pages in a standard manner. In addition, the applicant may communicate via chat 
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with a customer service agent who also is connected to the application database and may 
change the state of the application according to information received by the applicant via 
chat. In the embodiment shown, the customer service agent interacts with a special 
purpose counter offer server that uses the information provided by the applicant to 
determine a counter offer using information in the application database. The counter 
offer is stored in the application database and provided to the applicant's browser via the 
web server. As noted above, the counter offer server and the web server may be 
implemented on a single machine referred to as the application server. The various 
processes operating on the application server, the chat server and the browser are 
described below for the purpose of illustrating how the chat window may be activated 
and a counter offer generated for the applicant. 

Figure 2 is a flowchart illustrating a general process implemented on the chat 
server. The process starts at 200. In a step 202, the applicant identifier is obtained from 
a browser. In a step 204, the chat server validates the applicant information by 
communicating with the application database. In some embodiments, the chat server may 
communicate directly with the application database. In other embodiments, as shown in 
Figure 1, the chat server communicates with the application database through an 
application server. After the applicant information is validated, a response is received 
from the applicant via chat. Based on the response, the applicant account is configured in 
a step 208 and the process ends at 210. 

Figure 3 is a flow chart illustrating a general process implemented on the web 
server for sending dynamic web pages to the applicant. The dynamic web pages differ 
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from a standard web page used to interact with the applicant because they contain a page 
object used to initiate a chat section with a chat server upon the occurrence of certain 
events. The page object includes an applicant identifier that is passed to the chat server. 
The process starts at 300 when chat is initiated based on a user action. As described 
above, the user action may be the activation of a help or chat button or the user canceling 
out of the application. Chat may also be activated by user inaction when a response is not 
received or by an improper action taken by a user resulting in an invalid response. In a 
step 302, the state of the application is determined. Next, in a step 304, the content of the 
page to be sent to applicant is determined based on the state of the application. Next, in a 
step 306, the applicant identifier is inserted into a page object. In a step 308, the page is 
sent to the applicant browser and the process ends at 310. 

Figure 4 is a flow chart illustrating a process implemented on a browser for 
establishing a connection to a chat server. The process starts at 400. In a step 402, a link 
to the chat server is activated either directly by the user or as a result of the occurrence of 
an event as described above. In a step 404, a connection is established to the chat server. 
Typically the connection uses a protocol such as HTTPS. Next, in a step 406, the 
applicant identification is sent to the chat server and the process ends at 408. 

Figure 5 is a flowchart illustrating a typical process implemented on the browser 
for the purpose of initializing chat when the user does not respond to a downloaded web 
page in a certain period of time. The process starts at 500. In a step 502, a timer is 
initialized. Control is then transferred to 504 where periodic checks are made to 
determine whether the timer has expired. If a valid user input is received, control is 
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transferred to a step 506 and the timer is reset. If the timer expires, then control is 
transferred to a step 508 and a chat session is initiated as described above. The process 
then ends at 510. 

Figure 6 is a flow chart illustrating a process implemented on a chat server when a 
chat session is requested by a browser as described above. The process starts at 600 
when the request is received. The request for a chat session includes both a connection 
request and the applicant identifier. In a step 602, the request is put into a queue and the 
applicant identifier is stored in a manner that associates it with the request. In some 
embodiments, the chat server uses the applicant identifier while the request is still in the 
queue to obtain the application information from the application database. In other 
embodiments, the applicant identifier is not used to access the application database until 
the request is assigned to a customer service agent. This insures that when the customer 
service agent accesses the information about the application, the information is up to 
date. In a step 604, a status message is sent to the user and the system then waits for an 
available customer service agent. So long as no customer service agent is available, the 
system continues to wait at 604. When a customer service agent becomes available, 
control is transferred to a step 606 and the application information is sent to the customer 
service agent. The customer service agent then uses the application information to 
discuss the state of the application with the applicant. 

Figure 7A is a flow chart illustrating a process implemented at a customer service 
agent for the purpose of supporting the chat session. The process may be implemented 
on a client machine accessed by the customer service agent or may be implemented on 
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the application server which may include a dedicated counter-offer server. The process 
starts at 700. In a step 702, the customer service agent notifies the chat server that it is 
available. Next, in a step 704, the applicant identifier is received from the chat server. In 
a step 706, the applicant record in the application database is accessed using the applicant 
identifier as mentioned above. The application record may be accessed either directly or 
via the application server. In a step 708, the chat server displays the application data 
retrieved using the applicant identifier to the customer service agent. In one embodiment, 
the application data is displayed by displaying the same web page that the applicant is 
viewing. In addition, the web page may be augmented with other information about the 
status of the application. Alternatively, a completely separate application information 
screen may be displayed to the customer service agent. 

In an embodiment where a counter offer is generated by the customer service 
agent, a display is provided showing various offer terms that the applicant may indicate 
are not acceptable in the chat between the applicant and the customer service agent. The 
customer service agent may check one or more of the terms and the terms checked by the 
customer service agent are sent to the counter offer server to be used in generating a 
counter offer. The terms or attributes of the offer that the applicant considers to be 
unacceptable are obtained in a step 712 and the initial process for receiving applicant 
information and providing information to the counter offer server ends at 714. 

It should be noted that a number of different methods of obtaining the 
unacceptable terms from the applicant may be used. In one embodiment, as described 
above, a set of offer terms are shown to the customers service agent and the customer 
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service agent selects terms identified by the applicant in chat that are unacceptable. In 
other embodiments, a display of terms is provided to the applicant and the applicant picks 
the unacceptable terms with the aid of the customer service agent. In yet another 
embodiment, the chat generated by the applicant is automatically analyzed by a program 
which generates the list of unacceptable terms for the counter offer server. 

Figure 7B is a screen shot illustrating a display of offer terms used in one 
embodiment for determining which terms are unacceptable. The display includes 
indications that interest rate attributes are not acceptable, indicating that the annual 
percentage rate or long term interest rate is too high, a longer introductory interest rate is 
desired, or an introductory interest rate is desired. The introductory interest rate is a very 
low rate offered for a short period of time when the account is established, also referred 
to as a teaser rate. In addition, buttons are provided for the customer service agent to 
check whether the credit limit is too low either for purchases or for balance transfers. In 
addition, the customer service agent can fill in a balance transfer amount that the 
applicant wants to transfer as well as a requested credit limit. Finally, a box is provided 
for the customer service agent to check and send the data to the counter offer server. 

Figure 8 is a flow chart illustrating in detail a process implemented in step 712 for 
obtaining the unacceptable terms of an offer from an applicant. The process starts at step 
800. In a step 802, a chat message is received from a user indicating a term that the user 
would like to change. The message is displayed to the customer service agent along with 
a checklist as shown in Figure 7b illustrating terms to change. As noted above, the 
checklist may also be displayed and checked by the applicant. In a step 806, an input is 
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received from the customer service agent of a selected term of an offer that the applicant 
would like to change. In a step 808, the term is sent to the counter offer server and the 
process ends at 810. 

Figure 9 is a flow chart illustrating the process implemented on the counter offer 
server when more than one term is selected as being unacceptable to the applicant. In 
one embodiment, a counter offer is selected based on only one unacceptable term being 
changed. This simplifies the process of determining a counter offer since changing two 
terms is somewhat more complex. Therefore, a hierarchy of terms that may be changed 
by the applicant is provided and the highest priority term selected is used to determine the 
counter offer. All of the unacceptable terms are still transmitted to the counter offer 
server and recorded for the purpose of data gathering and analysis of the system. The 
process starts at 900. In a step 902, multiple unacceptable terms or attributes of the offer 
are received by the counter offer server. Next, in a step 904, the highest priority term or 
attribute that is unacceptable is determined. Next, in a step 906, the offer is adjusted and 
a counter offer is determined based on the highest priority term. The process ends at 908. 

Many different methods may be used by the counter offer server to generate a 
counter offer based on attributes or terms identified by the applicant as being 
unacceptable. In one embodiment, a number of potential offers are identified based on 
the applicant information provided and an assessment of the risk associated with 
extending credit to the applicant. Some of the generated offers are withheld while others 
are displayed to the applicant. A number of schemes may be used to decide which offers 
are displayed and which offers are withheld. Some methods may include a statistical 



Attorney Docket No. NEXTP005C1 



19 



Patent 



selection or a selection according to a marketing scheme designed to increase the rate of 
acceptance. It may also be the case that the best offer is withheld and kept in reserve to 
use as a counter offer. In general, certain potential offers are withheld. 

The identification by the applicant of an unacceptable term is used by the counter 
offer server to identify a better offer for the counter offer. In one embodiment, offer 
strategies are identified and the counter offer is identified by simply looking up an offer 
strategy associated with the applicant and the identified unacceptable term. In one 
embodiment, an offer strategy may include a set of offers shown to the applicant as well 
as offers that are not displayed and that correspond to various unacceptable terms. When 
an unacceptable term is identified, the offer corresponding to the strategy and the 
unacceptable term is used as the counter offer. 

In some embodiments, the counter offer strategy is dependent on characteristics of 
the applicant. For example, the applicant may be classified as a "surfer" or "non-surfer". 
A "surfer" is a person who shifts or surfs balances among credit cards, taking advantage 
of low teaser rates. A determination that an applicant is a surfer is made based on an 
analysis of the applicant's credit report. A counter offer strategy designed for such an 
applicant may adopt the strategy of extending the period of an introductory rate if 
requested by the applicant, but requiring the applicant to make a certain number of 
purchases or not transfer the balance for a certain period of time. 

In general, added terms and conditions such as purchase requirements or a length 
of time that a balance may not be transferred from the card may be added to counter 
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offers for the purpose of creating a perceived barrier to receive the counter offer. Such a 
barrier or condition prevents the applicant from deciding that the first offer should always 
be rejected. In some embodiments, the conditions are determined based on 
characteristics of the applicant. As described above, surfers may receive balance transfer 
time restrictions. 

In addition to selecting a withheld offer based on a pre-determined offer scheme, 
the counter offer server may also recalculate a customized offer based on the 
identification of an unacceptable term and an actual requested term by the applicant. For 
example, the applicant may express that the credit limit is too low, either for a desired 
balance transfer that the applicant wants to make or new purchases. The amount of the 
credit limit minus the amount of the balance transfer is referred to as the amount of credit 
that is "open to buy". The information sent to the counter offer server may include a 
requested credit limit and a requested balance transfer amount. From that information, 
the counter offer server can determine that the offer credit limit is too low either for the 
balance transfer requested or for the amount that the applicant wants open to buy. To 
minimize risk, it is desirable that the credit limit be as low as possible. Therefore, it is 
desirable not to simply select a withheld offer with a higher credit limit, but instead to 
customize an offer that conforms to the applicant's request but does not exceed the 
applicant's request. 

Accordingly, a new credit limit may be calculated that incorporates the requested 
balance transfer and the amount that the applicant wants open to buy. The calculated new 
offer is checked versus the risk profile of the user and it is verified that the higher credit 



Attorney Docket No. NEXTP005C1 



21 



PATENT 



limit is appropriate for the user. Any of the various techniques well known in the art of 
assigning credit may be used to assess the risk of the applicant and determine an 
appropriate upper credit limit. Significantly, the counteroffer in the case of a requested 
higher credit limit is specifically customized for the applicant based on what the applicant 
requests. In general, any counter offer provided is based on the applicant's identification 
of an unacceptable term. In some embodiments, if no counter offer is available that 
improves an unacceptable term identified by the applicant, then a message is returned to 
the applicant either directly or through the chat interface that indicates that no counter 
offer can be provided at that time. For example, in one embodiment, the offer strategy 
may include an offer with the best annual percentage rate available in the set of offers 
initially displayed to the applicant. In such a case, if the applicant identifies the annual 
percentage rate as the unacceptable term, then no counter offer improving that term can 
be generated. 

Figure 10 is a flow chart illustrating an example process for generating a counter 
offer. The process starts at 1000. In a step 1010, the counter offer server receives the 
term that is to be changed. Next, in a step 1020, it is determined whether the term is the 
credit limit or not. If the term is not the credit limit, then control is transferred to a step 
1030 and a precomputed offer that was withheld is determined for display. The counter 
offer determination process then ends at 1040. If the term is the credit limit, then control 
is transferred to a step 1050 and it is determined whether the credit limit is too low for a 
requested balance transfer or for new purchases (open to buy). If the credit limit is too 
low for new purchases, then control is transferred to a step 1060 and the required balance 
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transfer and credit limit are adjusted if that is allowed by the scheme being used to assign 
credit based on an assessment of the applicant's risk. 

If the credit limit is too low for a requested balance transfer, then control is 
transferred to a step 1070 and the credit limit is adjusted based on the balance transfer 
requested if allowed by the credit line assignment being used. After the credit limit is 
adjusted in steps 1060 or 1070, the counter offer is defined and the counter offer 
determination process ends at 1080. Whether a precomputed offer is determined for 
display in 1030 or the credit limit is recomputed in step 1060 or 1070, if no better offer 
can be generated, then a message noting that no better offer can be generated is sent 
either to the chat server or to the applicant directly. 

Once a counter offer has been defined or it has been determined that no counter 
offer that improves the unacceptable terms can be generated, the applicant is notified of 
the counter offer terms. In different embodiments, notification may be accomplished in 
various ways. For example, in one embodiment, a new offer page is generated in the 
application server based on data written to the application database by the application 
server. In the embodiment where the application server is split into a web server and a 
counter offer server, the counter offer server writes data to the application database and 
the web server generates a counter offer page based on the data written to the application 
database. In addition, the application server also provides information to the chat server 
indicating what counter offer, if any, has been generated. The customer service agent 
then discusses the counter offer with the applicant via the chat interface. In order to view 
the counter offer page generated by the web server, the applicant is asked to refresh his 
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browser. Refreshing the browser causes the offer page to be requested from the web 
server and the web server responds with the counter offer page. In one embodiment, a 
button labeled "view offer" is provided on the displayed page. When the button is 
selected, the page is downloaded again and any changes are then viewed by the user. 

In other embodiments, the displaying of the counter offer page to the applicant is 
handled somewhat differently. In one embodiment, the chat server enables the display of 
the page through the applicant's browser automatically, without requiring the applicant to 
refresh the screen. This can be accomplished in a variety of ways. In one embodiment, 
the chat server writes a variable to a memory location that the browser checks 
periodically. When the browser checks the location and finds a variable indicating that 
the counter offer page should be downloaded, the browser automatically refreshes itself. 
The applet that enables the browser to check the location and refresh itself may be used in 
some cases but not others. When such an applet is not used, the process of instructing the 
applicant through the chat interface to refresh his own browser or to select a button to 
view the offer may be implemented. 

Figure 1 1 is a flowchart illustrating a process implemented on a counter offer 
server to generate and confirm a new offer for display to the applicant. The process starts 
at 1 100. In a step 1110, the counter offer server receives a chat-generated term to 
change. As described above, the term can be identified based on chat by a customer 
service agent or the term can be automatically determined by analysis of the chat 
provided by the applicant or the term can be identified using a pick list provided to the 
applicant. In a step 1 120, a new offer is selected from an offer set included in the offer 
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strategy being used for the applicant. As described above, in some embodiments, a new 
offer is actually calculated based on information provided by the applicant such as a 
requested credit limit. Next, in a step 1 130, the new offer is displayed to the customer 
service agent. The customer service agent then communicates with the applicant about 
the new offer to determine the applicant's interest. The customer service agent then 
confirms to the counter offer server that the new offer is to be shown to the applicant. 
The confirmation is received in step 1 140 and in a step 1 150, the counter offer server 
confirms the new offer in the data base so that it is ready to be displayed when the 
applicant's browser refreshes. The process then ends at 1 160. 

In some embodiments, the new offer is confirmed in the database concurrent with 
it being displayed to the customer service agent. Then, whenever the applicant's browser 
refreshes, the counter offer will be displayed. In some embodiments, it is desired that the 
display of the counter offer not be enabled until customer service agent has an 
opportunity to chat with the applicant about the new offer and confirm that display is 
appropriate. 

Figure 12 is a flowchart illustrating a process implemented on the web server 
portion of the application server for the purpose of displaying a new counter offer to the 
applicant. The process starts at 1200. In a step 1210, the web server receives a refresh 
request from the applicant's browser. Next, in a step 1220, the counter offer parameters 
are retrieved from the application database and a web page including the counter offer is 
generated. Then in a step 1230, the counter offer page is sent to the browser. The 
process ends at 1240. 
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Figure 13 is a flow chart illustrating a process used in one embodiment to 
automatically generate a refresh on the applicant's browser. The process starts at 1300. 
In a step 1310, a request is received for a different offer from the customer service agent. 
The new offer is determined in a step 1320. The terms of the new offer are 
communicated to the customer service agent in step 1330. In a step 1340, the customer 
service agent describes the offer to the user. Then, in a step 1350, the customer service 
agent receives an indication that the user wants to view the new offer. The customer 
service agent then sends a message to the user in step 1360 that causes a refresh to be 
activated. As described above, the message may include writing a certain value to a 
defined memory location that is periodically examined by the browser for the purpose of 
determining whether a refresh has been requested by the customer service agent. Once 
one refresh is generated in this manner, the value that the browser looks for may be 
incremented so that each time it finds the same value, a new refresh is not generated. The 
process ends at 1370. 

A system and method for activating a chat interface with a customer service agent 
that has access to information about an application for credit has been described. In one 
embodiment, the chat interface is used to obtain information about why an applicant is 
rejecting an offer of credit and to identify unacceptable terms. Those unacceptable terms 
are communicated to a counter offer server and the counter offer server generates a new 
offer that improves the unacceptable term. The new offer is communicated to the 
applicant using the chat interface and a web page showing the new offer with an 
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opportunity to accept the offer is displayed to the applicant when the applicant's browser 
is refreshed. 

Although the foregoing invention has been described in some detail for purposes 
of clarity of understanding, it will be apparent that certain changes and modifications may 
be practiced within the scope of the appended claims. It should be noted that there are 
many alternative ways of implementing both the process and apparatus of the present 
invention. Accordingly, the present embodiments are to be considered as illustrative and 
not restrictive, and the invention is not to be limited to the details given herein, but may 
be modified within the scope and equivalents of the appended claims. 

WHAT IS CLAIMED IS: 
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